home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9505 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: lrz-muenchen.de!news
  2. From: watzka@stat.uni-muenchen.de (Kurt Watzka)
  3. Newsgroups: gwu.seas,comp.lang.c
  4. Subject: Re: help: gcc
  5. Date: 11 Mar 1996 16:07:41 GMT
  6. Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
  7. Distribution: world
  8. Message-ID: <4i1j4d$mpn@sparcserver.lrz-muenchen.de>
  9. References: <4hpiht$1n2@cronkite.seas.gwu.edu> <4i0l50$js0@hpbblb.bbn.hp.com>
  10. NNTP-Posting-Host: sun2.lrz-muenchen.de
  11.  
  12. Matthias Dittrich <matti> writes:
  13.  
  14. >spiffy@seas.gwu.edu (Marc Goldberg) wrote:
  15. >>
  16. >>Trying to compile a program on Solaris 2.5, I've removed all bugs (syntax 
  17. >>errors, at least) but these.  Any help would be *greatly* appreciated.
  18. >>
  19. >>Thanks,
  20. >>--Marc
  21. >>
  22. >>~~~~~
  23. >>spiffy@felix:5: gcc 2FarmCheck.c 
  24. >>2FarmCheck.c: In function `readHostFiles':
  25. >>2FarmCheck.c:23: dereferencing pointer to incomplete type
  26. >>2FarmCheck.c:25: dereferencing pointer to incomplete type
  27. >>2FarmCheck.c:27: warning: passing arg 3 of `fgets' from incompatible 
  28. >>         pointer type
  29. >>2FarmCheck.c: In function `main':
  30. >>2FarmCheck.c:66: storage size of `PID' isn't known
  31. >>~~~~~~
  32. >>
  33. >>The lines referred to are:
  34. >>
  35. >>char *readHostFiles(char *name)
  36. >>      {
  37. >>      int foo;
  38. >>      struct FILE *fileDisc;
  39.  
  40. FILE _is_ a "struct _iobuf" or something similar in most implementations.
  41. So, struct FILE is an incomplete type, and is _not_ related to FILE,
  42. because struct "tags" and typedefed names live in different namespaces.
  43.  
  44. >>
  45. >>(23)  *fileDisc = fopen("/users/spiffy/urls.txt", O_RDONLY);
  46.  
  47. The function fopen()  I know returns a "FILE *". So, if fileDisc would
  48. be defined as "FILE *fileDisc", no dereferencing would be needed.OTOH,
  49. the function I know takes a "const char *" as it's second argument,
  50. so maybe we are talking about different functions.
  51.  
  52. >>
  53. >>(25)  while (!feof(fileDisc))
  54. >>        {
  55. >>(27)      if ( fgets(name, HOSTNAMESIZE, fileDisc) != name)
  56. >>          exit(12);
  57. >>        }
  58.  
  59. In C, feof() is not endowed with clairvoyance, a simple fgets() would
  60. do all you need to both read a line from the file and find out 
  61. whether you have reached the end of that file.
  62.  
  63. >>      return name; 
  64. >>      } 
  65. >>|
  66. >>|
  67. >>|
  68. >>int main(void)
  69. >>      {
  70. >>(66)  struct pid_t PID;
  71.  
  72. This is _very_ system specific, but if you are talking about a
  73. system that is somehow similar to the system I am thinking about
  74. (happens to be Solaris 2.4), a pid_t is certainly not a struct,
  75. but it might have been introduced by something like 
  76.  
  77.    typedef long pid_t;
  78.  
  79. Again, "struct pid_t" is an incomplete type that is _not_ related
  80. to the typedef name "pid_t".
  81.  
  82. >>      char name[HOSTNAMESIZE];        /*Hostname of server to check on*/
  83. >>
  84. >>      PID = getpid();
  85. >>      ...other stuff...
  86. >>      }
  87.  
  88. >You have to include the header files which are defining the missung types and
  89. >functions. These should be stdio.h for file handling and sys/unistd.h for
  90. >getpid() and pid_t.
  91.  
  92. I do _not_ agree with this analysis. Without a prototype for fgets()
  93. in scope, the argument type mismatch for that function could not
  94. have been detected.
  95.  
  96. The main source of the problem seems to be that struct "tags" and
  97. typedefed names do not live in the same namespace, so the compiler
  98. is not able do diagnose the kind of confusion that the original
  99. poster suffers from.
  100.  
  101. Kurt
  102. --
  103. | Kurt Watzka                             Phone : +49-89-2180-6254
  104. | watzka@stat.uni-muenchen.de
  105. | ua302aa@sunmail.lrz-muenchen.de
  106.